5.5.3 プロダクトリスク
「ソフトウェアやシステムで失敗する可能性のある領域」
↑ 次に起きる事象が意に沿わなかったり、危険を引き起こしたりする可能性
故障の起きやすいソフトウェアの出荷
改修にかかるコストは、そのまま開発した企業にとって損失になる
ソフトウェアやハードウェアが個人や会社に対して損害を与える可能性
PL法の観点から「瑕疵担保責任」を負わなければならない事態も…
訴訟に至ると責任が作り手になくとも風評被害なども影響出てくるかも
使い勝手やレスポンスが期待を満たしていなければ、製品の信頼感や魅力の喪失に繋がる 貧弱なデータの完全性と品質
プロダクトが目的を果たせないリスク
データ移行、変換、伝送の上で問題発生
データそのものが規定する標準に準拠していない
機能は仕様通りでもデータがおかしくて動かないことも
予定の機能が動作しないソフトウェア
事前予防策、事前準備策、事後対応策を検討する
ただ、考えられるすべてで行うことはなく、優先度付けを行う
発生可能性、発火した時の損害（リスクエクスポージャ）、影響度などで判断する
リスクが高い機能に対し、リスクが軽減されていることを確認する方法 やっぱり、テストが期待通り動くこと
強力な事前予防策と言える
テストを事前予防策として考慮していない場合
前フェーズで検出されるべき不具合が多いため、本来のテストケースが実施できない ムラがあって、プロダクトリスクの高い機能に対してのテストが十分にできない
開発担当者がテスト実施中でもモジュールを更新しちゃう ISTQBでは洗い出したリスクに対しては以下のように対処するとしている
リスクの優先度が高い機能のテストケースは網羅率が高くなるようなテスト技法を選択する
テストを実行する範囲を決める
実施する構成をどれだけ組むのか
重大な欠陥をなるべく早い時期に検出するため、テストの優先順位を決める
リスクベースでテストの優先順位を決める
スケジュール遅延の時でもリスクの高いテストは飛ばすわけにはいかない
コストや納期のトレードオフの決断の際の制約を弱くする
テスト以外でリスクを減らす方法があるか考える
開発担当者のトレーニングなど
リスクが顕在化した時のための機能実装
自動アップデート、リストアなどなど